Computer systems, such as smartphones, personal digital assistants, tablets, netbooks, laptops, and desktops, typically include a processor, communication unit such as a bus, power supply, and, optionally, a housing unit. Often, computer systems are configured to function with peripheral devices, which are termed “devices” for purposes of this application.
Devices may be categorized by the position of each relative to a housing unit. For example, internal devices—called also “integrated devices”—generally are stored inside or integrated with the housing unit. Such integrated devices may include an internal hard drive, CD-R drive, CD-ROM drive, DVD-ROM drive, sound card, network card, video adapter, or an internal modem. External devices, on the other hand, generally are stored outside of the housing unit and may include a printer, scanner, monitor, touchscreen, keyboard, or pointing devices such as a mouse, gaming controller, or joystick.
Devices may be categorized also by function. For example, storage devices may include an external hard drive, flash drive, disk drive, or any other device configured to permit information storage. Input devices may include keyboard, pointing devices such as a mouse, gaming controller, or joystick, digital camera, webcam, barcode reader, microphone, fingerprint scanner, or any other device configured to permit input of information into the computer. Output devices may include display devices such as a monitor, segment display such as a digital clock display, television set, or tactile electronic display, audio output devices such as speakers or headphones, printers, or any other device configured to permit information output from the computer.
Many devices are configured to provide an output that is perceivable by a user. For purposes of this application, a “perceivable output” may include any perceptible output from the device including, for example, that which is viewable on a display, a touchable button, a light, or stored information. Other perceivable outputs may be input from one device—e.g., a keyboard or a mouse—and perceived as an output on a display device—such as a monitor or a touchscreen.
Computer systems may use hardware, software, or both to manage the resources of the computer system. Software used to manage a computer system's resources is termed an “operating system.” When a user seeks to use a device with a computer system, the operating system may not have the information necessary to communicate with that device. Because of the plethora of devices available to connect with computer systems, it would be impractical to include the information necessary for communicating with every device in every operating system. Accordingly, a software program—called a “device driver” or “driver”—allows the device and operating system to communicate with each other. Generally, at least one driver is available for every type of device. At times, a driver may be developed for each of multiple operating systems (e.g., Microsoft Windows, Mac OS X, Android, Linux, BSD, etc.). When the driver permits communication between the operating system and a physical device, the device can perform its function to generate a perceivable input/output.
Drivers also may be used to facilitate communication between the operating system and an application program. An application program—also referred to herein as an “app”—may be configured to permit the user to perform a specific task. Popular apps may include word processing programs, image editing programs, game programs, database management programs, and document management programs. Certain apps may be configured for use specifically with a device. Such an app is termed a “device application program” for purposes of this application.
Conventionally, a driver or an app utilizing a device through the driver could not be developed until the physical device, or at least a stable prototype of the physical device, was completed. Clearly, such a delay in the development and validation of the driver further delays offering of the product for sale. At times, developers begin designing drivers based on predictions of the physical device. When the physical device becomes available, draft versions of the driver often require substantial revisions, which results in a largely inefficient process.
To shorten the development cycle, systems have been built to enable earlier development of a driver. One such approach includes using an early prototype such as a Field-Programmable Gate Array (“FPGA prototype”) for driver development. However, such prototypes can delay the start of driver development until the register transfer level (“RTL”) design of the device is generally finished. Also, an FPGA prototype may differ significantly from the physical device. As a result, the driver developed to work with that prototype may need significant revision in order that it can function with the physical device.
In addition, known approaches for testing an FPGA prototype, or even the physical device, during driver development permit only limited observation of the internal conditions of the prototype or device. Also, prototypes and physical devices generally do not permit recording events that occurred, for example, before an error, and are difficult to control without a time-consuming and labor-intensive bootstrapping process.
Another approach to enable the development of a driver involves the utilization of virtual machines and virtual devices. A “virtual machine” is a software program configured to simulate the operation of certain hardware or operating system with minimal access to the actual hardware or operating system in the host computer system. In certain embodiments, a virtual machine is a simulated computer system operating within, but generally isolated from, a physical computer system.
A “virtual device” is a software program configured to simulate the operation of or function as a physical device without access to the physical device or a prototype of the physical device. In various embodiments, a virtual device may be configured to have the same functional restrictions and other restrictions as physical devices. In various embodiments, a virtual device may be presented as a virtualized replacement of a physical device.
Virtual devices may operate within an environmental infrastructure such as a virtual machine or an operating system. When functioning in a virtual machine, a guest operating system may interact with a virtual device as if it is a physical device. This requires no change to the driver stack of the guest operating system. In contrast, when functioning in a non-virtual operating system, an operating system may be extended to allow loading of a virtual device as if it is a physical device. This involves changing the driver stack of the operating system. An example of this approach is the Device Simulation Framework (“DSF”), which allows introduction of virtual devices that model and simulate Universal Serial Bus (“USB”) devices in an operating system.
While certain virtual devices are known, such virtual devices have not been optimized for device simulation and driver development. Specifically, certain known virtual devices are too simple to permit development of a driver that consistently functions with the physical device. Other known virtual devices are too complex to create an efficient simulation. For example, certain virtual devices permit observation, tracking, and control of the device, but often result in excess performance overhead and cause the simulation to operate slowly.
In addition, known virtual devices use concrete execution of software code. In other words, to achieve a certain task, a program may execute instructions that include one or more if-then statements (e.g., if A, then B; if not A, then C). In concrete execution, the developer must predetermine which choice the program will make at each decision point. Accordingly, to simulate each physical device behavior, a developer must explicitly specify concrete values and choices or supply run-time scripts for each device behavior. Such virtual devices render it difficult to conduct comprehensive exploration of possible device behaviors and simulation of the possible concurrency in device-driver interaction.
Other known device simulations are not configured to operate in virtualization environments such as DSF and a Quick EMUlator (“QEMU”) virtual machine. Such simulations include those generated from device designs at different stages within the development process, for example, transaction-level (“TL”) designs in SystemC or SystemVerilog, register-transfer-level (“RTL”) designs in Verilog or VHDL, and gate-level (“GL”) designs as net-lists.
In addition, methods for preparing testing protocols for known virtual devices and the co-developed drivers typically must be generated manually and/or on a case-by-case basis, which is time-intensive and cost-prohibitive.
Clearly, there is a demand for a system and methods for constructing virtual devices that incorporate various levels of detail from a device design, developing a driver or application program with improved performance, preparing automated testing protocols for validating a driver, driver-device combination, or application program, and verifying conformance between virtual devices and their real counterparts, where such system and methods are configured to maximize the smooth integration of the resulting driver or application program with a physical device.